Systems and methods for proactive caching utilizing OLAP variants

ABSTRACT

The present invention leverages MOLAP performance for ROLAP objects (dimensions, partitions and aggregations) by building, in a background process, a MOLAP equivalent of that object. When the background processing completes, queries are switched from ROLAP queries to MOLAP queries. When changes occur to relevant relational objects (such as tables that define content of OLAP objects), an OLAP object is switched back to a ROLAP mode, and all relevant caches are dropped while, as a background process, a new MOLAP equivalent is created.

RELATED APPLICATIONS

This application is a divisional of U.S. patent application Ser. No.10/402,000, filed Mar. 28, 2003, now U.S. Pat. No. 7,269,581 entitled“SYSTEMS AND METHODS FOR PROACTIVE CACHING UTILIZING OLAP VARIANTS”which is incorporated herein by reference.

TECHNICAL FIELD

The present invention relates generally to caching data, and moreparticularly to systems and methods for proactively caching datautilizing OLAP variants.

BACKGROUND OF THE INVENTION

Computing and networking technologies have transformed many importantaspects of everyday life. Computers have become a household stapleinstead of a luxury, educational tool or entertainment center, andprovide users with a tool to manage and forecast finances, controlhousehold operations like heating, cooling, lighting and security, andstore records and images in a permanent and reliable medium. Networkingtechnologies like the Internet provide users with virtually unlimitedaccess to remote systems, information and associated applications.

As computing and networking technologies become robust, secure andreliable, more consumers, wholesalers, retailers, entrepreneurs,educational institutions and the like are shifting paradigms andemploying networks, such as the Internet, to perform business instead ofthe traditional means. For example, many businesses and consumers areproviding web sites or on-line services. For example, today a consumercan access his/her account via the Internet and perform a growing numberof available transactions such as balance inquiries, funds transfers andbill payment.

Typically, a network session includes a user interfacing with a clientapplication to interact with a server that stores information in adatabase that is accessible to the client application. For example, astock market web site can provide the user with tools for retrievingstock quotes and purchasing stock. The user can type in a stock symboland request a stock quote by performing a mouse click to activate aquery. The client application queries a database table of stocks andreturns a stock quote.

A shortcoming of computing and networking technologies is the limitedbandwidth. A user consumes a portion of the bandwidth whereby theportion consumed is not available to other users. Therefore, as more andmore users employ a network, the available bandwidth decreases which canreduce response time and performance. Another shortcoming of computingand networking technologies is the limited available data transfer ratesrelative to the quantity of data available. For example, requests thatretrieve large amounts of data (e.g., distributed across variousservers) can be time intensive, which can diminish performance also.

Thus, Business Intelligence (BI) solutions were developed to aid inaccessing information about large databases. Most businesses in recenttimes have migrated to relational type databases. Data warehouses weredeveloped to store tactical information to answer the “who” and “what”questions about the stored data related to previous events. However,this proved limiting due to the fact that data warehouses only have thecapability of retrieving historical data. Therefore, on-line analyticalprocessing (OLAP) systems were developed to not only answer the “who”and “what”, but also the “what if” and “why” of the data. OLAP systemsare multidimensional views of aggregate data that allow analysts,business managers, and executives to gain insight into the informationthrough a quick, reliable, interactive process.

Analysis tools, including OLAP tools, help to reduce the access times toextreme amounts of data. By utilizing these tools, a user can askgeneral questions or “queries” about the data rather than retrieve allthe data verbatim. Thus, “data about data” or metadata helps expeditethe query process and reduce the required network bandwidth. However, asis typical in a business environment, what was fast yesterday isconsidered slow by today's standard. There is always an increasingdemand for faster information delivery, in spite of the exponentiallyexpanding sizes of data stores.

SUMMARY OF THE INVENTION

The following presents a simplified summary of the invention in order toprovide a basic understanding of some aspects of the invention. Thissummary is not an extensive overview of the invention. It is notintended to identify key/critical elements of the invention or todelineate the scope of the invention. Its sole purpose is to presentsome concepts of the invention in a simplified form as a prelude to themore detailed description that is presented later.

The present invention relates generally to caching data, and moreparticularly to systems and methods for proactively caching datautilizing OLAP variants. OLAP variants are leveraged to create multiplequery sources about a data source. By efficiently convertingmultidimensional object based on the data source to an OLAP variantcache, such as a MOLAP (Multidimensional OLAP) cache, users gain anability to have queries quickly analyzed and also maintain a capabilityto access the data source real-time. The present invention also allowsfor interactive participation by the user as to when a variant isutilized, providing faster and more user-oriented query responses thanby employing a non-proactive caching scheme.

The present invention also facilitates data analysis by decreasing theneed to directly access large databases through employment of a cachebased, in part, on multidimensional analysis data, extending theusefulness of existing data structures and providing quick and efficientanalysis of extremely large databases. Because all OLAP variants havestrengths and weaknesses, a system utilizing a single variant generallydoes not satisfy a user completely, returning stale data and/orresponding slowly. The present invention drastically decreases the queryresponse time and, at the same time, enables real-time information to beextracted, allowing a user to receive data quickly and seeminglytransparent as to the variant utilized to respond to a query, maximizinguser-friendliness, increasing the speed of information retrieval, andproviding reliable information regardless of the variant employed.

To the accomplishment of the foregoing and related ends, certainillustrative aspects of the invention are described herein in connectionwith the following description and the annexed drawings. These aspectsare indicative, however, of but a few of the various ways in which theprinciples of the invention may be employed and the present invention isintended to include all such aspects and their equivalents. Otheradvantages and novel features of the invention may become apparent fromthe following detailed description of the invention when considered inconjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary proactive caching process in accordancewith an aspect of the present invention.

FIG. 2 is a block diagram of a database serving system in accordancewith an aspect of the present invention.

FIG. 3 is another block diagram of a database serving system inaccordance with an aspect of the present invention.

FIG. 4 is yet another block diagram of a database serving system inaccordance with an aspect of the present invention.

FIG. 5 is a block diagram of a cache development structure in accordancewith an aspect of the present invention.

FIG. 6 is another block diagram of a cache development structure inaccordance with an aspect of the present invention.

FIG. 7 is a block diagram of a proactive caching system in accordancewith an aspect of the present invention.

FIG. 8 is another block diagram of a proactive caching system inaccordance with an aspect of the present invention.

FIG. 9 is a block diagram of proactive caching system inputs inaccordance with an aspect of the present invention.

FIG. 10 is a block diagram of proactive caching system parameters inaccordance with an aspect of the present invention.

FIG. 11 is yet another block diagram of proactive caching system inaccordance with an aspect of the present invention.

FIG. 12 is a flow diagram illustrating a method of proactive caching inaccordance with an aspect of the present invention.

FIG. 13 is another flow diagram illustrating a method of proactivecaching in accordance with an aspect of the present invention.

FIG. 14 is yet another flow diagram illustrating a method of proactivecaching in accordance with an aspect of the present invention.

FIG. 15 is still yet another flow diagram illustrating a method ofproactive caching in accordance with an aspect of the present invention.

FIG. 16 is still yet another flow diagram illustrating a method ofproactive caching in accordance with an aspect of the present invention.

FIG. 17 is still yet another flow diagram illustrating a method ofproactive caching in accordance with an aspect of the present invention.

FIG. 18 illustrates an example operating environment in which thepresent invention can function.

FIG. 19 illustrates another example operating environment in which thepresent invention can function.

FIG. 20 illustrates yet another example operating environment in whichthe present invention can function.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is now described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of the present invention. It may be evident, however, thatthe present invention may be practiced without these specific details.In other instances, well-known structures and devices are shown in blockdiagram form in order to facilitate describing the present invention.

As used in this application, the term “component” is intended to referto a computer-related entity, either hardware, a combination of hardwareand software, software, or software in execution. For example, acomponent may be, but is not limited to being, a process running on aprocessor, a processor, an object, an executable, a thread of execution,a program, and/or a computer. By way of illustration, both anapplication running on a server and the server can be a computercomponent. One or more components may reside within a process and/orthread of execution and a component may be localized on one computerand/or distributed between two or more computers. A “thread” is theentity within a process that the operating system kernel schedules forexecution. As is well known in the art, each thread has an associated“context” which is the volatile data associated with the execution ofthe thread. A thread's context includes the contents of system registersand the virtual address belonging to the thread's process. Thus, theactual data comprising a thread's context varies as it executes.

Since no single OLAP variant can provide both low latency and real-timedata, the present invention leverages MOLAP performance for ROLAPobjects (dimensions, partitions and aggregations) by building, as abackground process, a MOLAP equivalent of that object. When thebackground processing is completed, object usage is switched to MOLAPqueries, enabling much faster query response times. As changes occur torelevant relational objects (such as tables that define a content of theOLAP objects), the OLAP object is switched back to a ROLAP mode, and allthe relevant caches are dropped while, in the background, a new MOLAPequivalent is created. Thus, the MOLAP equivalent is employed to providea cache which is proactively controlled depending upon the mode beingutilized to process the queries. This allows a user to get the benefitof immediate browsing of data (and/or to always reflect the mostup-to-date picture of a relational database) without paying the typicalperformance price of querying ROLAP objects. This permits the user toperceive the present invention as a shim layer of metadata around adatabase, such as a relational database and the like, always providingthe most up-to-date data as quickly as possible. In order to achievemaximum global performance users have various options by which they canfine tune proactive caching and influence its behavior vis-à-vis ofchanges in a relational database (these options are detailed infra).

If a user is interested in viewing the most recent data (real-timeOLAP), but doesn't want the delay inherent in browsing ROLAP data, theuser can instruct a system to build, in a background transaction, anequivalent MOLAP object and to “switch” the queries to use a MOLAP“image” instead. When changes occur to underlying relational objects,the system automatically responds to them as soon as they occur andopens a short transaction that reverts an object back to a ROLAP mode.Then, the system will re-open the background transaction and rebuild theMOLAP image. Should an update happen while the background transaction isin progress, MOLAP processing is canceled and the background transactionis restarted. These background transactions are somewhat “second classcitizens” in the sense that they can be canceled in case a userinitiated transaction needs to lock an object in a mode incompatiblewith a current locking mode of an object, due to a backgroundtransaction.

In FIG. 1, an exemplary proactive caching process 100 in accordance withan aspect of the present invention is illustrated. The proactive cachingprocess 100 starts 102 and a ROLAP object is processed into a MOLAPcache 104. The process 100 is completed 106, unless a cancel isreceived, invoking a check on whether a database has changed 108. If thedatabase has no changes 108, the process 100 is completed 106. However,if the database has changes 108, the process 100 is rescheduled andstarts again 102. In a typical instance of the present invention,actions are generated by a user 110. These actions 110 can includecommitting of processing of a ROLAP object 112 which initiates theprocess 100. Another action generated by the user 110 can includestarting another transaction on the ROLAP object 114, canceling anexisting ROLAP object to MOLAP cache process 104. A system can alsoautomatically detect conditions 116 such as, for example, a databasechange 118 and the like. Once a database change 118 has occurred, anexisting ROLAP object to MOLAP cache process 104 is canceled.

A user can also specify a minimum duration of “quiet time” via a “quiettime delay” feature before starting a background transaction of buildinga new MOLAP image. This allows multiple cross-transaction insert/updatesinto an OLTP (On-Line Transaction Processing) (many OLTP applicationsupdate transactional data this way, by individual inserts at a certainmoment in time). This reduces the query stress that an OLAP server putson an OLTP system by repetitive queries. The quiet time delay isaccomplished by a component that keeps track of a “last updated” time ofany involved tables.

Similar to the quiet time delay feature, an optional “delayed”triggering feature specifies that all changes are tracked in abackground thread that treats accumulated changes every designated timeperiod (a configurable interval). In the logical scheme, this feature isimplemented by a queue implementation in between the two threads, all ofthe invocations being handled through this queue. This feature permits anotification mechanism that can be presented by certain providers toprevent overloading an OLTP with queries that ask whether the tableswere updated or not. Generally, this is accomplished on a per serverbasis (not per object) because it describes a notification behavior of awhole proactive caching subsystem.

Another feature allows for “manual” changes to be made via a means for auser to mark certain tables/views/ROLAP objects as being “dirty”,triggering the above process manually. This is typically done by a DDL(Data Definition Language) statement that can be sent to a serverthrough a regular mechanism, e.g., XML/A (extensible MarkupLanguage/Analysis) and the like. In one aspect of the present invention,there can be two categories of marking: relational object marking(potentially can affect multiple ROLAP objects) and/or ROLAP objectmarking (basically bootstrapping a relational layer as far asdependencies are concerned).

Yet another feature permits a means for creating a list of trackingtables. A user can label tables that affect a certain ROLAP object. Theadvantages of doing this include the following. One advantage of thisfeature is that if a certain table on which an object is based upon isnot a real table but a view or a DSV (Data Set Viewer) view (namedquery), it would be hard to track events on whether a view changed(typical notification mechanisms—SQL (Structured Query Language)notification and triggers operate on tables and materialized views, notregular views and named queries). In the absence of this feature, theonly reasonable way of tracking changes to a view is to parse its SQLdefinition (but, again, it might be based on other views by itself andparsing SQL is not a reasonable approach). Another advantage is relatedto the “manual” change feature. Often, it is desirable to mark an objectas dirty even if it doesn't have bindings to a certain table but thattable changed.

In one aspect of the present invention, the means has a capability forlisting tables in at least one of two places: 1) Within a DSV, a list ofalternate tables is provided for proactive caching tracking. Thus, forproactive caching purposes, when a ROLAP object depends on this table,it registers itself as actually depending on alternate tables. It isdesirable that the alternate tables are trackable relational objects(tables and/or materialized views, not views). 2) Within a ROLAP object,a list of alternate/additional tables is provided by which to track theobject. This is often needed for objects that do not have necessarybindings to relational objects within a DSV (partitions). It isdesirable that these tables are trackable objects as well (tables and/ormaterialized views).

Still yet another feature provides a means for a “Limited latency”. Thisfeature specifies a duration between a start of a new MOLAP imagecreation and a cancellation of an old MOLAP image and reverting to ROLAP(if any). In one aspect of the present invention, by default, thisduration is zero (basically, two transactions—one that rolls back anobject to ROLAP and one that starts building a MOLAP engine—start inparallel). Advantages of this feature include having a duration in whichqueries go to a ROLAP store drops to a minimum and providing analysis atthe end of building a MOLAP image of a ROLAP proactive cached dimension(in case an expiration interval didn't pass yet). If a change was trulyincremental, a proactive cached partition is not affected. If a changeaffected non-granularity attributes, it can drop (revert to ROLAP andreschedule) flexible aggregations and leave everything else untouched.Otherwise, the means reverts dependent partitions/aggregations to ROLAP.

A “quiet time override” feature provides a means to specify that if thisamount of time after an initial notification is reached, MOLAP imagingkicks in unconditionally. However, it should be noted that, in oneaspect of the present invention, if a MOLAP imaging has been started dueto an override and if another notification comes while this is inbuilding, that notification does not cancel the MOLAP imaging that is inprogress. It is recorded for normal treatment (while if a processing hasbeen started using a “normal” path, a notification results in thecanceling of a MOLAP imaging if the current storage mode is ROLAP).

A “force rebuild” feature specifies that a MOLAP imaging startsunconditionally at this time after a fresh image has been built. In oneaspect of the present invention, if notifications come while this is inprogress, they are queued for normal treatment.

Turning to FIG. 2, a block diagram of a database serving system 200 inaccordance with an aspect of the present invention is shown. Thedatabase serving system 200 is comprised of a proactive caching system202, multidimensional objects 208, such as “OLAP objects” and the like,with a multidimensional objects subset 232, and a database 210 with acapability of accepting updates 218. The proactive caching system 202 iscomprised of an analysis component 204 and at least one cache 206 with acache subset 230. This system 200 provides query analysis and responseto users via the proactive caching system 202. The proactive cachingsystem 202 leverages multidimensional objects 208 based on the database210 to provide a system for providing low latency responses and/orreal-time responses while remaining seemingly transparent to a user.

In this aspect of the present invention, the analysis component 204 hasinputs comprising a query input 220, a user input 212, a system input214, and a database input 216 for update notifications and the like. Inother instances of the present invention, the database input 216 is partof the system input 214. The analysis component 204 has a cacheinterface 222 and a multidimensional objects interface 224. Theseinterfaces 222, 224 provide access from the analysis component 204 tothe cache 206 and/or the multidimensional objects 208, dependent upon adesired query response (i.e., proactively seeking an appropriate cachefor an appropriate response). In other aspects of the present invention,the analysis component has a cache subset interface 226 to the cachesubset 230 and a multidimensional objects subset interface 228 to themultidimensional objects subset 232. The subset interfaces 226, 228provide access to subsets of the cache 206 and the multidimensionalobjects 208 while other parts of the cache 206 and/or themultidimensional objects 208 are being updated. The cache 206 iscomprised of information derived from the multidimensional objects 208.The multidimensional objects 208 are based on the database 210.

In one instance of the present invention, a system for cachinginformation is comprised of at least one multidimensional object 208providing dynamic multidimensional analysis data derived from a database210, at least one cache 206 providing dynamic multidimensional analysisdata from at least one multidimensional object 208 and at least oneanalysis component 204 coupled to the multidimensional object 208 andthe cache 206 for proactively controlling access to the multidimensionalobject 208 and the cache 206. In other instances of the presentinvention, the multidimensional object 208 is comprised of OLAP objects,such as ROLAP objects and the like. In yet another instance of thepresent invention, the analysis component 204 is comprised of a UDM(Unified Dimensional Model). In still yet another instance of thepresent invention, the cache 206 is comprised of a MOLAP cache and thelike. Other instances of the present invention include, but are notlimited to, the multidimensional object 208 comprising real-time accessanalysis data and the cache 206 comprising quick access analysis data.Even other instances of the present invention include a database 210being comprised of a relational database.

Additional instances of the present invention also include a proactivecaching system 202 that is comprised of an analysis component 204, acache 206, and a multidimensional objects interface 224 that allows foraccessing at least one multidimensional object 208. The analysiscomponent having capabilities to control access to the multidimensionalobjects 208 and to the cache 206. Thus, it is not necessary for themultidimensional objects 208 to be part of the proactive caching system202. The multidimensional objects 208 can be part of a databasemanagement system. The present invention, therefore, allows flexibilityin its employment by having a capability to be utilized with existingdatabase management systems. This enhances existing systems, maximizingtheir usefulness while increasing their performance.

Further instances of the present invention additionally include aproactive caching system 202 that is comprised of an analysis component204, a cache interface 222 that allows for accessing and controlling acache 206, and a multidimensional objects interface 224 that allows foraccessing at least one multidimensional object 208. Thus, the cache 206can reside external to the proactive caching system 202. This allowseven greater flexibility in implementing the present invention toexisting platforms with caching resources already available.

Referring to FIG. 3, another block diagram of a database serving system300 in accordance with an aspect of the present invention is depicted.The database serving system 300 is comprised of a proactive cachingsystem 302, multidimensional objects 308, such as OLAP objects and thelike, and a database 310 with a capability of accepting updates 318. Theproactive caching system 302 is comprised of an analysis component 304and a cache 306. In this aspect of the present invention, the analysiscomponent 304 has inputs comprising a query input 320, a user input 312,a system input 314, and a database input 316 for update notificationsand the like. In other instances of the present invention, the databaseinput 316 is part of the system input 314. The analysis component 304has a multidimensional objects interface 322. In this aspect of thepresent invention, the cache 306 is being built in a backgroundoperation based on the multidimensional objects 308. Therefore, theanalysis component 304 is not actively interfacing to respond to querieswith the cache 306 at this particular time. Thus, the analysis component304 responds to query inputs 320 by accessing the multidimensionalobjects 308 only.

Moving on to FIG. 4, yet another block diagram of a database servingsystem 400 in accordance with an aspect of the present invention isillustrated. The database serving system 400 is comprised of a proactivecaching system 402, multidimensional objects 408, such as OLAP objectsand the like, and a database 410 with a capability of accepting updates418 to a database table 426. The proactive caching system 402 iscomprised of an analysis component 404 and a new cache 406. In thisaspect of the present invention, the analysis component 404 has inputscomprising a query input 420, a user input 412, a system input 414, anda database input 416 for update notifications and the like. In otherinstances of the present invention, the database input 416 is part ofthe system input 414. The analysis component 404 has a multidimensionalobjects interface 422. In this aspect of the present invention, the newcache 406 is being built in a background operation from themultidimensional objects 408. Therefore, the analysis component 404 isnot actively interfacing to respond to queries with the new cache 406 atthis particular time. Thus, the analysis component 404 responds to queryinputs 420 by accessing the multidimensional objects 408 only.Additionally, an update 418 is received that affects the database table426. In this example of one aspect of the present invention, the changein the database table 426 also affects the multidimensional objects 408from which the query input 420 relies upon for a response. Thus, an oldcache 424, based on database data prior to the update 418, is removedand the new cache 406 is built in a background process of the proactivecaching system 402 in order to reflect the latest database data update.In other instances of the present invention, the removal of the oldcache 424 can be caused by a user input 412 and/or a system input 414.

Turning to FIG. 5, a block diagram of a cache development structure 500in accordance with an aspect of the present invention is shown. Thestructure 500 is comprised of a database 502 containing a database table510, a metadata set 504, a dimensional model (multidimensional objectssuch as “OLAP objects” and the like) 506, and a cache 508. Typically,information about data from the database 502 is compiled into themetadata set 504. Metadata objects are constructed from the metadata set504 to form the dimensional model 506. The dimensional model 506 usuallyincludes dimensions, cubes, and measures and the like. This allows anOLAP management tree to access the metadata objects in the dimensionalmodel 506. In this manner, a cache 508 with dynamic multidimensionalanalysis data derived from a multidimensional object based on a relevantdatabase can be constructed from the dimensional model 506.

Continuing on with FIG. 6, another block diagram of a cache developmentstructure 600 in accordance with an aspect of the present invention isshown. In this instance of the present invention, the structure 600 iscomprised of a relational database 602 containing a relational databasetable 610, a metadata set 604, ROLAP objects 606, and a MOLAP cache 608.In this example, the MOLAP cache 608 is constructed from ROLAP objectsderived from the metadata set 604 and the relational database 610.Having two different OLAP data set variants available (e.g., ROLAP andMOLAP variants and the like), allows for proactively accessing anappropriate data set to transparently deliver a query response in afashion desired by a user and/or a system.

In FIG. 7, a block diagram of a proactive caching system 700 inaccordance with an aspect of the present invention is illustrated. Theproactive caching system 700 is comprised of an analysis component 702,a cache 704 with a cache subset 720, and multidimensional objects 706,such as OLAP objects and the like, with a multidimensional objectssubset 722. In one aspect of the present invention, the analysiscomponent 702 comprises a query interpreter 710, a low latency terminal714, and a real-time terminal 712. The analysis component 702 can acceptinputs such as a user input 716, a system input 718, and a query input708 and the like. In one aspect of the present invention, the queryinterpreter 710 can parse or resolve a complex query into “parts” andproactively decide which terminal 712, 714 is appropriate based uponcontent of the query input 708. For example, Part #1 can be labeled“time sensitive data” and be directed to the low latency terminal 714 inorder to access the cache 704 and, specifically, the cache subset 720.Likewise, Part #2 can be labeled “latest data” and be directed to thereal-time terminal 712 in order to access the multidimensional objects706 and, specifically, the multidimensional objects subset 722. In asimilar fashion, Part #n (where “n” represents an integer from 1 toinfinity) can be labeled as either of the above categories and bedirected to either the cache 706 and/or the multidimensional objects708. In yet another aspect of the present invention, parsing of thequery input 708 can be based on the user input 716 and/or the systeminput 718 (including database statuses and the like). Although “lowlatency” and “real-time” are described as “terminals,” they are in factpart of the analysis component and do not need to be separate entitiesas depicted in FIG. 7. Thus, these can be included as part of the queryinterpreter 710, as part of the cache 706 and/or the multidimensionalobjects 704 as an embedded filter that controls incoming data, and/or aspart of an external filter.

Referring to FIG. 8, another block diagram of a proactive caching system800 in accordance with an aspect of the present invention is shown. Theproactive caching system 800 is comprised of an analysis component 802,a cache 804, and multidimensional objects 806, such as OLAP objects andthe like. In one aspect of the present invention, the analysis component802 comprises a query interpreter 816, a low latency terminal 818, and areal-time terminal 820. The query interpreter 816 handles multiple queryinputs 808. This can include any number of inputs, but for the sake of abrief illustration, three inputs are shown. These inputs include User #1input 810, User #2 input 812, and User #3 input 814. Each user inputconstitutes at least one query which the query interpreter 816 analyzes.For example, if the first User #1 input contains Query #1 with adimension of “product info” and database status relative to thatinformation of “database stable”, the query interpreter 816 can directthat access to the low latency terminal 818 for accessing the cache 804.The cache 804 can be a multidimensional OLAP cache with fast responsetime and the like. If the second User #2 input contains Query #2 with adimension of “demographics” and database status relative to thatinformation of “database updating”, the query interpreter 816 can directthat access to the real-time terminal 820 for accessing themultidimensional objects 806. The multidimensional objects'characteristics can include real-time data access and the like.Likewise, if the third User #3 input has a dimension of “financial data”and a database status relative to that information of “databaseupdating”, the query interpreter 816 can direct that access to thereal-time terminal 820 for accessing the multidimensional objects 806.In this fashion, the proactive caching system 800 provides a user withdesired responses without having active user input as to which cache isto be utilized. However, the present invention does not precludeutilizing user and/or system inputs to determine how and/or when toproactively cache.

Turning to FIG. 9, a block diagram of proactive caching system inputs900 in accordance with an aspect of the present invention isillustrated. As described supra, an analysis component 902 can havemultiple inputs. These include, but are not limited to, query inputs904, user inputs 906, and system inputs 908. User inputs 906 include,but are not limited to, quiet time delay 910, quiet time delay override912, forced refresh time 914, user initiated partial cache rebuild 916,and user input “n” 918 (where “n” represents any unlimited number and/ortypes of inputs), and the like. System inputs 908 include, but are notlimited to, last database update tracker 920, tables affecting OLAPobjects 922, dependent OLAP objects data source tracker 924, and systeminput “n” 926 (where “n” represents any unlimited number and/or types ofinputs), and the like.

Quiet time delay 910 is comprised of a means to keep track of how muchtime has passed since a database has been updated relative to somepertinent information. That pertinent information can be an actual datatable entry and/or an OLAP object. Quiet time override 912 is comprisedof a means determined by a system and/or a user to override and rebuilda cache even though the quiet time delay 910 has not been met. Thisprevents a cache from never being updated due to sporadic but frequentupdates to a database, always occurring just before the quiet time delay910 is reached. Forced refresh time 914 is comprised of a means to forcea refresh of the cache at a given interval. This prevents a cache fromcontaining stale data in spite of the fact that a database has notreported any updates within the forced refresh time 914. This alsoensures that even in a case where the database is unable to send statusdata, the cache can be updated. User initiated partial cache rebuild 916is comprised of a means to allow a user to control what portion and/orwhen that portion of the cache is to be rebuilt. This allows a user toselectively decide if a particular subset, for example, should berebuilt while retaining other data for quick accessibility. User input“n” 918 is comprised of any means for aiding in proactive caching by theanalysis component 902. One skilled in the art can appreciate that manydifferent timing parameters and/or data parameters can be input by auser to aid in more effectively utilizing proactive caching. One suchmeans, for example, includes allowing a user to input manual changes tomark certain tables/views/OLAP objects as requiring an update.

Last database update tracker 920 is comprised of a means to track whenthe database was last updated. This input can be utilizes along withother inputs to determine the staleness of cache data and the like.Tables affecting OLAP objects 922 is comprised of a means to track/listdatabase table data that is related to an OLAP object that a cache isbased upon. This allows filtering of caching updates to prevent updatingthe cache when a database has an unrelated table update. Dependent OLAPobjects data source tracker 924 is comprised of a means to track adependency of cache data to a particular OLAP object. This also allowsfiltering of caching updates to prevent updating a cache when anunrelated OLAP object changes. System input “n” 926 is comprised of anymeans for aiding in proactive caching by the analysis component 902. Oneskilled in the art can appreciate that many different timing parametersand/or data parameters can be input by a system to aid in moreeffectively utilizing proactive caching. This includes, but is notlimited to, database update notifications and the like also.

It is important to note that although the above input parameters areillustrated as going to the analysis component 902, the analysiscomponent 902 itself can include subcomponents that providefunctionality to perform the functions necessary to utilize the inputsdescribed above. It is also possible for external components to theanalysis component 920 to provide some and/or all of the functionalityrequired.

In FIG. 10, a block diagram of proactive caching system parameters 1000in accordance with an aspect of the present invention are shown. In oneinstance of the present invention, the proactive caching systemparameters 1000 are comprised of operational modes 1002 and triggers1010 and the like. The operational modes are comprised of ROLAP Mode1004, MOLAP mode 1006, and MOLAP/ROLAP mode 1008 and the like. Thetriggers 1010 for ROLAP Mode 1004 are comprised of quiet time delay met1012, quiet time delay override met 1014, forced refresh time met 1016,and database update 1018 and the like. The triggers 1010 for MOLAP Mode1006 are comprised of an equivalent MOLAP and ROLAP data set 1020 and auser demand for quick query response 1022 over a need for real-time dataand the like. The triggers 1010 for MOLAP/ROLAP Mode are comprised ofwhen low latency and real-time queries are both required 1024 and whenpartial rebuilding of a MOLAP cache is required 1026.

ROLAP Mode 1004 allows only ROLAP data to be accessed for queries. Thisis typically a slower mode with real-time data access. MOLAP Mode 1006only allows MOLAP data to be accessed for queries and is typically adefault mode due to its quick performance. To ensure data integrity andincreased performance, MOLAP Mode can be employed anytime MOLAP dataequals ROLAP data. This insures that no data accuracy is lost byutilizing the faster means. It can also be employed by a user demandingquick access over a need for real-time data and the like (other userinputs). MOLAP/ROLAP Mode 1008 is a hybrid mode that allows access toboth MOLAP and ROLAP data. This permits a user and/or system to retrieveany type of data desired at any type of latency desired. It also permitspartial rebuilding of the MOLAP cache with ROLAP objects providinginformation for that portion of the MOLAP cache under construction.

One skilled in the art can appreciate that the aforementioned triggersand operational modes are in no way exhaustive lists. FIG. 10 representsan example only of one aspect of the present invention. Additional modesand triggers can also be employed within the scope of the presentinvention as well.

Looking at FIG. 11, yet another block diagram of proactive cachingsystem 1100 in accordance with an aspect of the present invention isillustrated. The proactive caching system comprising an analysiscomponent 1102, a MOLAP cache 1104, and OLAP objects 1106. The analysiscomponent 1102 comprising an adaptive tuning component 1110, a firstsession 1114, and a second session 1116. The adaptive tuning component1110 comprising a query interpreter 1112, a performance optimizer 1118,and a result comparator 1120. A typical query 1108 is input into thequery interpreter 1112. In this aspect of the present invention, thequery interpreter 1112 is part of the adaptive tuning component 1110.Therefore, for performance tuning, the query interpreter 1112establishes a dual session with the same query 1108. Thus, the query1108 is sent via session #1 1114 to the MOLAP cache 1104 and via session#2 1116 to the OLAP objects 1106. Each session 1114, 1116 produces aresponse that is sent to the result comparator 1120. The resultcomparator 1120, in turn, determines any differences between the twosessions 1114, 1116. These differences, if any, are reported to theperformance optimizer 1118. The performance optimizer 1118 tracks thedifferences and adaptively alters how the query interpreter 1112 reactsto future queries. One skilled in the art will recognize that not allqueries need to be continuously processed via the two sessions 1114,1116. Once a particular query has been optimized, an occasional samplingis all that is required. “Occasional” can be per minute, hourly, daily,monthly and/or yearly and the like depending on the frequency that datais queried. For example, previous sales records from a year ago canresult in identical results whether via session #1 1114 or session #21116. Thus, when queried about sales records for the same time period,the performance optimizer 1118 instructs the query interpreter 1112 toonly utilize the MOLAP cache 1104 for a quick response. The performanceoptimizer 1118 can track data, usage, and associated parameters toprovide adaptive tuning even to user settings, possibly providing a userwith performance suggestions.

In view of the exemplary systems shown and described above,methodologies that may be implemented in accordance with the presentinvention will be better appreciated with reference to the flow chartsof FIGS. 12-17. While, for purposes of simplicity of explanation, themethodologies are shown and described as a series of blocks, it is to beunderstood and appreciated that the present invention is not limited bythe order of the blocks, as some blocks may, in accordance with thepresent invention, occur in different orders and/or concurrently withother blocks from that shown and described herein. Moreover, not allillustrated blocks may be required to implement the methodologies inaccordance with the present invention.

The invention may be described in the general context ofcomputer-executable instructions, such as program modules, executed byone or more components. Generally, program modules include routines,programs, objects, data structures, etc. that perform particular tasksor implement particular abstract data types. Typically the functionalityof the program modules may be combined or distributed as desired invarious embodiments.

Turning to FIG. 12, a flow diagram illustrating a method 1200 ofproactive caching in accordance with an aspect of the present inventionis depicted. The method 1200 starts 1202 by beginning to build a MOLAPcache equivalent of ROLAP objects in a background process 1204. Adetermination is then made to detect when the MOLAP cache is completed1206. When completed, operational mode is switched to utilizing theMOLAP mode 1208. Queries are then processed employing the MOLAP cache1210. A determination is then made as to whether there has been anyrelevant change to the ROLAP objects 1212. This can include any relevantchanges to any underlying data also. If no relevant changes have beenmade, queries are continued to be processed utilizing the MOLAP cache1210. However, if changes are present, the operational mode is switchedto ROLAP mode 1214. All relevant caches are then dropped 1216, endingthe flow 1218. This cycle can be repeated indefinitely in order to keepthe MOLAP cache fresh in spite of any relevant database changes.

Moving on to FIG. 13, another flow diagram illustrating a method 1300 ofproactive caching in accordance with an aspect of the present inventionis shown. The method 1300 starts 1302 by providing a user input 1304. Adetermination is made as to whether a MOLAP mode request was made 1306.If not, queries are continued to be processed utilizing ROLAP mode 1322,ending the flow 1316. However, if a MOLAP mode request is made, a MOLAPequivalent of ROLAP objects are built as a background process 1308. Adetermination is then made as to whether changes relevant to the ROLAPobjects have occurred 1310. If changes have occurred, the MOLAPequivalent build is canceled 1318, the operational mode is switched toROLAP mode 1320, and a MOLAP equivalent of the ROLAP objects is againconstructed 1308. However, if no relevant changes have occurred aftercompleting the build of the MOLAP cache, the operational mode isswitched to MOLAP mode 1312 and query processing utilizes the MOLAPcache 1314, ending the flow 1316.

Referring to FIG. 14, yet another flow diagram illustrating a method1400 of proactive caching in accordance with an aspect of the presentinvention is illustrated. The method 1400 begins 1402 with a quiet timedelay user input provided 1404. A MOLAP equivalent of ROLAP objects isconstructed in a background process 1406. A determination is then madeas to whether any relevant changes have occurred to the ROLAP objects1408. If no changes have occurred, queries are processed utilizing theMOLAP cache 1410, ending the flow 1412. However, if changes haveoccurred to the ROLAP objects, a determination is made as to whether thequiet time delay has been met 1414. If not, a determination is made asto whether a quiet time delay override has been met 1418. If the quiettime delay override has not been met, the queries are processed usingthe MOLAP cache 1410, ending the flow 1412. However, if the quiet timedelay override has been met, an operational mode is switched to ROLAPmode and a MOLAP cache is once again constructed 1406. If, however, thequiet time delay has been met after detecting relevant changes to theROLAP objects, the operational mode is switched to ROLAP mode 1416 andthe MOLAP cache is built in a back ground process 1406, continuing thecycle.

Turning to FIG. 15, still yet another flow diagram illustrating a method1500 of proactive caching in accordance with an aspect of the presentinvention is shown. The method 1500 starts 1502 by providing a manualuser input 1504. The manual user input contains parameters that allow auser to designate certain tables/views/objects and the like as “dirty”(i.e., in need of updating if they are required to be accessed). Adetermination 1506 is made as to whether any relevant changes haveoccurred to ROLAP objects 1506. This takes into account that dirtyinputs may change data relevant to cached data. If no relevant changeshave occurred, queries are processed employing a MOLAP cache 1514,ending the flow 1516. Typically, due to a higher performance gain,utilizing MOLAP cache is a default condition for a proactive cachingsystem and is performed unless directed otherwise by a user and/or asystem. However, if relevant changes have occurred to the ROLAP objects1506 (due to the dirty inputs and/or database updates and the like),operational mode is switched to ROLAP mode 1508. The MOLAP cache is thenrebuilt in a background process 1510, and the operational mode isswitched to MOLAP mode once again 1512 when the cache is completed.Query processing then continues to employ the MOLAP cache 1514, endingthe flow 1516.

In FIG. 16, still yet another flow diagram illustrating a method 1600 ofproactive caching in accordance with an aspect of the present inventionis shown. The method 1600 starts 1602 by a user providing relative ROLAPobject data inputs 1604. The input data is then linked to appropriateROLAP objects as being pertinent 1606. In this manner, a user can tagdata as being relative to cached data even though it was not derivedspecifically from this data. A determination is then made as to whetherany relevant changes have occurred to ROLAP objects. This checks to seeif the new data links have established links from the ROLAP objects todata that has changed. If no changes are found, queries are processedemploying a MOLAP cache 1616, ending the flow 1618. Due to performancegains, MOLAP mode is considered the default mode. However if changeshave been made to relevant ROLAP objects 1608, operational mode isswitched to ROLAP mode 1610. A MOLAP cache is then rebuilt from theROLAP objects in a background process 1612. Once completed, theoperational mode is switched to MOLAP mode 1614 and queries are onceagain processed utilizing the MOLAP cache 1616, ending the flow 1618.

Looking at FIG. 17, still yet another flow diagram illustrating a method1700 of proactive caching in accordance with an aspect of the presentinvention is depicted. The method 1700 starts 1702 with a user providinga forced refresh rate input 1704. A determination is then made as towhether this input has been met 1706. If not, queries are processedutilizing a MOLAP cache 1714, ending the flow 1716. Due to performancegains, MOLAP mode is considered the default mode. However, if the forcedrefreshed rate input has been met 1706, operational mode is switched toROLAP mode 1708. The MOLAP cache is then rebuilt as a background process1710. Once completed, the operation mode is then switched back to MOLAPmode 1712 and queries are processed employing the MOLAP cache 1714,ending the flow 1716.

The aforementioned flows are meant to be representative flows of variousmethods of the present invention. They in no way encompass everyiteration and variance within the scope of the present invention. Thoseskilled in the art can appreciate that a method can incorporatemodifications and still remain within the purview of the presentinvention.

In order to provide additional context for implementing various aspectsof the present invention, FIG. 18 and the following discussion areintended to provide a brief, general description of a suitable computingenvironment 1800 in which the various aspects of the present inventionmay be implemented. While the invention has been described above in thegeneral context of computer-executable instructions of a computerprogram that runs on a local computer and/or remote computer, thoseskilled in the art will recognize that the invention also may beimplemented in combination with other program modules. Generally,program modules include routines, programs, components, data structures,etc. that perform particular tasks and/or implement particular abstractdata types. Moreover, those skilled in the art will appreciate that theinventive methods may be practiced with other computer systemconfigurations, including single-processor or multi-processor computersystems, minicomputers, mainframe computers, as well as personalcomputers, hand-held computing devices, microprocessor-based and/orprogrammable consumer electronics, and the like, each of which mayoperatively communicate with one or more associated devices. Theillustrated aspects of the invention may also be practiced indistributed computing environments where certain tasks are performed byremote processing devices that are linked through a communicationsnetwork. However, some, if not all, aspects of the invention may bepracticed on stand-alone computers. In a distributed computingenvironment, program modules may be located in local and/or remotememory storage devices.

As used in this application, the term “component” is intended to referto a computer-related entity, either hardware, a combination of hardwareand software, software, or software in execution. For example, acomponent may be, but is not limited to, a process running on aprocessor, a processor, an object, an executable, a thread of execution,a program, and a computer. By way of illustration, an applicationrunning on a server and/or the server can be a component. In addition, acomponent may include one or more subcomponents.

With reference to FIG. 18, an exemplary system environment 1800 forimplementing the various aspects of the invention includes aconventional computer 1802, including a processing unit 1804, a systemmemory 1806, and a system bus 1808 that couples various systemcomponents, including the system memory, to the processing unit 1804.The processing unit 1804 may be any commercially available orproprietary processor. In addition, the processing unit may beimplemented as multi-processor formed of more than one processor, suchas may be connected in parallel.

The system bus 1808 may be any of several types of bus structureincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of conventional bus architectures suchas PCI, VESA, Microchannel, ISA, and EISA, to name a few. The systemmemory 1806 includes read only memory (ROM) 1810 and random accessmemory (RAM) 1812. A basic input/output system (BIOS) 1814, containingthe basic routines that help to transfer information between elementswithin the computer 1802, such as during start-up, is stored in ROM1810.

The computer 1802 also may include, for example, a hard disk drive 1816,a magnetic disk drive 1818, e.g., to read from or write to a removabledisk 1820, and an optical disk drive 1822, e.g., for reading from orwriting to a CD-ROM disk 1824 or other optical media. The hard diskdrive 1816, magnetic disk drive 1818, and optical disk drive 1822 areconnected to the system bus 1808 by a hard disk drive interface 1826, amagnetic disk drive interface 1828, and an optical drive interface 1830,respectively. The drives 1816-1822 and their associatedcomputer-readable media provide nonvolatile storage of data, datastructures, computer-executable instructions, etc. for the computer1802. Although the description of computer-readable media above refersto a hard disk, a removable magnetic disk and a CD, it should beappreciated by those skilled in the art that other types of media whichare readable by a computer, such as magnetic cassettes, flash memorycards, digital video disks, Bernoulli cartridges, and the like, can alsobe used in the exemplary operating environment 1800, and further thatany such media may contain computer-executable instructions forperforming the methods of the present invention.

A number of program modules may be stored in the drives 1816-1822 andRAM 1812, including an operating system 1832, one or more applicationprograms 1834, other program modules 1836, and program data 1838. Theoperating system 1832 may be any suitable operating system orcombination of operating systems. By way of example, the applicationprograms 1834 and program modules 1836 can include a database servingsystem and/or a proactive caching system that utilizes data inaccordance with an aspect of the present invention. Additionally, theprogram data 1838 can include input data for controlling and/or biasinga proactive caching system in accordance with an aspect of the presentinvention.

A user can enter commands and information into the computer 1802 throughone or more user input devices, such as a keyboard 1840 and a pointingdevice (e.g., a mouse 1842). Other input devices (not shown) may includea microphone, a joystick, a game pad, a satellite dish, wireless remote,a scanner, or the like. These and other input devices are oftenconnected to the processing unit 1804 through a serial port interface1844 that is coupled to the system bus 1808, but may be connected byother interfaces, such as a parallel port, a game port or a universalserial bus (USB). A monitor 1846 or other type of display device is alsoconnected to the system bus 1808 via an interface, such as a videoadapter 1848. In addition to the monitor 1846, the computer 1802 mayinclude other peripheral output devices (not shown), such as speakers,printers, etc.

It is to be appreciated that the computer 1802 can operate in anetworked environment using logical connections to one or more remotecomputers 1860. The remote computer 1860 may be a workstation, a servercomputer, a router, a peer device or other common network node, andtypically includes many or all of the elements described relative to thecomputer 1802, although, for purposes of brevity, only a memory storagedevice 1862 is illustrated in FIG. 18. The logical connections depictedin FIG. 18 can include a local area network (LAN) 1864 and a wide areanetwork (WAN) 1866. Such networking environments are commonplace inoffices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, for example, the computer1802 is connected to the local network 1864 through a network interfaceor adapter 1868. When used in a WAN networking environment, the computer1802 typically includes a modem (e.g., telephone, DSL, cable, etc.)1870, or is connected to a communications server on the LAN, or hasother means for establishing communications over the WAN 1866, such asthe Internet. The modem 1870, which can be internal or external relativeto the computer 1802, is connected to the system bus 1808 via the serialport interface 1844. In a networked environment, program modules(including application programs 1834) and/or program data 1838 can bestored in the remote memory storage device 1862. It will be appreciatedthat the network connections shown are exemplary and other means (e.g.,wired or wireless) of establishing a communications link between thecomputers 1802 and 1860 can be used when carrying out an aspect of thepresent invention.

In accordance with the practices of persons skilled in the art ofcomputer programming, the present invention has been described withreference to acts and symbolic representations of operations that areperformed by a computer, such as the computer 1802 or remote computer1860, unless otherwise indicated. Such acts and operations are sometimesreferred to as being computer-executed. It will be appreciated that theacts and symbolically represented operations include the manipulation bythe processing unit 1804 of electrical signals representing data bitswhich causes a resulting transformation or reduction of the electricalsignal representation, and the maintenance of data bits at memorylocations in the memory system (including the system memory 1806, harddrive 1816, floppy disks 1820, CD-ROM 1824, and remote memory 1862) tothereby reconfigure or otherwise alter the computer system's operation,as well as other processing of signals. The memory locations where suchdata bits are maintained are physical locations that have particularelectrical, magnetic, or optical properties corresponding to the databits.

FIG. 19 is another block diagram of a sample computing environment 1900with which the present invention can interact. The system 1900 furtherillustrates a system that includes one or more client(s) 1902. Theclient(s) 1902 can be hardware and/or software (e.g., threads,processes, computing devices). The system 1900 also includes one or moreserver(s) 1904. The server(s) 1904 can also be hardware and/or software(e.g., threads, processes, computing devices). The servers 1904 canhouse threads to perform transformations by employing the presentinvention, for example. One possible communication between a client 1902and a server 1904 may be in the form of a data packet adapted to betransmitted between two or more computer processes. The system 1900includes a communication framework 1908 that can be employed tofacilitate communications between the client(s) 1902 and the server(s)1904. The client(s) 1902 are operably connected to one or more clientdata store(s) 1910 that can be employed to store information local tothe client(s) 1902. Similarly, the server(s) 1904 are operably connectedto one or more server data store(s) 1906 that can be employed to storeinformation local to the servers 1904.

Turning to FIG. 20, an example operating environment 2000 in which thepresent invention can function is shown. This typical environment 2000comprises an analysis services component 2002 linked to a data source2010 and user interfaces 2012. The user interfaces 2012 are comprised ofOLAP browsers, reporting tools, and other BI (Business Intelligence)applications and the like. The analysis services component 2002typically has an interface 2014 with the user interfaces 2012 viainterfaces 2008 like XML/A (extensible Markup Language/Analysis) and MDX(Multidimensional Exchange Language) and the like. The analysis servicescomponent 2002 is comprised of a UDM (Unified Dimensional Model)component 2004 and a cache 2006. In this example, the present inventionis employed within the analysis services component 2002 via the UDMcomponent 2004 and the cache 2006. The UDM component can proactivelyaccess the cache 2006 and/or the data directly.

What has been described above includes examples of the presentinvention. It is, of course, not possible to describe every conceivablecombination of components or methodologies for purposes of describingthe present invention, but one of ordinary skill in the art mayrecognize that many further combinations and permutations of the presentinvention are possible. Accordingly, the present invention is intendedto embrace all such alterations, modifications and variations that fallwithin the spirit and scope of the appended claims. Furthermore, to theextent that the term “includes” is used in either the detaileddescription or the claims, such term is intended to be inclusive in amanner similar to the term “comprising” as “comprising” is interpretedwhen employed as a transitional word in a claim.

1. A method for proactively caching data of a database utilizing onlineanalytical processing (OLAP) variants, the method being performed by aprocessor of a computer system having a database, the method comprising:creating a relational OLAP (ROLAP) object that represents data of thedatabase; building a multidimensional OLAP (MOLAP) cache equivalent ofthe ROLAP object such that the MOLAP cache stores the same data of thedatabase that is represented by the ROLAP object, the MOLAP cache andROLAP object being stored on the computer system; receiving a firstquery, at the computer system, for a portion of the data; accessing theMOLAP cache to resolve the first query; receiving an indication, at thecomputer system, that the data of the database represented by the ROLAPobject has been updated; rebuilding the MOLAP cache such that the MOLAPcache contains the updated data; receiving a second query, at thecomputer system, for a portion of the data while the MOLAP cache isbeing rebuilt; accessing the ROLAP object to resolve the second querywhile the MOLAP cache is being rebuilt; receiving a third query, at thecomputer system, for a portion of the data after the MOLAP cache isrebuilt; and accessing the MOLAP cache to resolve the third query. 2.The method of claim 1, wherein the MOLAP cache is built and rebuiltusing a background process.
 3. The method of claim 1, furthercomprising: receiving an indication while the MOLAP cache is beingrebuilt that the data of the database has been updated; and restartingthe rebuild of the MOLAP cache to account for the update to the data. 4.The method of claim 1, wherein rebuilding of the MOLAP cache is startedafter a specified amount of time after the update to the data occurs. 5.The method of claim 1, further comprising: receiving user input thatspecifies that the MOLAP cache should be rebuilt; and rebuilding theMOLAP cache in response to the user input.
 6. The method of claim 1,further comprising: rebuilding the MOLAP cache after a specified amountof time even when the data of the database has not been updated.
 7. Acomputer storage medium storing computer executable instructions whichwhen executed by a processor of a computer system proactively cache dataof a database utilizing online analytical processing (OLAP) variants,the computer executable instructions performing the following: creatinga relational OLAP (ROLAP) object that represents data of the database;building a multidimensional OLAP (MOLAP) cache equivalent of the ROLAPobject such that the MOLAP cache stores the same data of the databasethat is represented by the ROLAP object, the MOLAP cache and ROLAPobject being stored on the computer system; receiving a first query, atthe computer system, for a portion of the data; accessing the MOLAPcache to resolve the first query; receiving an indication, at thecomputer system, that the data of the database represented by the ROLAPobject has been updated; rebuilding the MOLAP cache such that the MOLAPcache contains the updated data; receiving a second query, at thecomputer system, for a portion of the data while the MOLAP cache isbeing rebuilt; accessing the ROLAP object to resolve the second querywhile the MOLAP cache is being rebuilt; receiving a third query, at thecomputer system, for a portion of the data after the MOLAP cache isrebuilt; and accessing the MOLAP cache to resolve the third query. 8.The computer storage medium of claim 7, wherein the MOLAP cache is builtand rebuilt using a background process.
 9. The computer storage mediumof claim 7, wherein the computer executable instructions furtherperform: receiving an indication while the MOLAP cache is being rebuiltthat the data of the database has been updated; and restarting therebuild of the MOLAP cache to account for the update to the data. 10.The computer storage medium of claim 7, wherein rebuilding of the MOLAPcache is started after a specified amount of time after the update tothe data occurs.
 11. The computer storage medium of claim 7, wherein thecomputer executable instructions further perform: receiving user inputthat specifies that the MOLAP cache should be rebuilt; and rebuildingthe MOLAP cache in response to the user input.
 12. The computer storagemedium of claim 7, wherein the computer executable instructions furtherperform: rebuilding the MOLAP cache after a specified amount of timeeven when the data of the database has not been updated.